代码自动提交
你会学到什么
上一节讲了版本控制——AI 改完代码你要看 diff。本节聚焦 diff 确认没问题之后的事：怎么提交。核心内容：Conventional Commits 规范（简要）、AI 提交工具怎么用（重点）、怎么调整和定制（重点）。
学完后，你的每次提交只需说一句话，AI 自动生成规范 message，你审查确认即可。
Conventional Commits 规范（30秒速览）
所有主流前端项目都用这个格式，AI 提交工具默认遵循：
<type>(<scope>): <subject>
text
| type | 用途 | 示例 |
|---|---|---|
feat | 新功能 | feat(button): 支持主题切换 |
fix | 修复 bug | fix(input): 修复 Safari 下光标消失 |
docs | 文档 | docs(readme): 补充安装说明 |
refactor | 重构 | refactor(table): 提取排序逻辑 |
test | 测试 | test(button): 补充禁用状态测试 |
build | 构建工具/CI | build: 升级 Vite 构建配置 |
chore | 杂项/工具 | chore: 升级依赖版本 |
perf | 性能 | perf(list): 虚拟滚动优化 |
style | 样式（不影响逻辑） | style: 统一缩进为2空格 |
这些 type 和上一节分支命名（feature/fix/docs/refactor）是同一套词汇体系，分支用它开头，提交也用它开头，整个仓库历史一目了然：哪些是新增特性、哪些是修的 bug。
好的 commit message 标准就一条：不看 diff 就能理解改了什么。 知道这个就够了，具体怎么写交给 AI。
提交前一次性配置：用户信息
第一次提交前检查 git config 里的用户名和邮箱。没配置的话，Git 会用默认用户名 + 本机主机名拼一个提交者——历史记录里会留下脏数据。以前要记 git config --global user.name 一串命令，现在自然语言一句话：
> 配置 git 用户名为 brian、邮箱为 brian@example.com，并把之前那条提交的作者一并修正
text
只想在本项目生效、不动全局配置，加一句"只配置当前项目，不要全局"即可。修改历史提交的作者、修改提交信息、分支合并、强制推送这类"高危记忆题"，如今全部可以这么自然语言描述完成。
AI 提交工具怎么用（重点）
场景一：用 Claude Code 开发（推荐）
你在 Claude Code 里改完代码，直接说：
> 提交代码
text
也可以用 /commit 命令——它来自 Claude Code 官方插件市场（claude-code-plugins，默认安装），内置 Conventional Commits 格式的提交流程，效果等价且更稳定。
Claude Code 会：
- 运行
git diff分析所有变更 - 判断是 feat/fix/refactor 等类型
- 从文件路径推断 scope（模块名）
- 生成 subject + body
- 展示给你确认
实际效果：
> 提交代码
AI 分析变更：
- src/components/Button.vue: 新增 theme prop
- src/styles/theme.css: 新增 CSS 变量定义
- tests/Button.test.ts: 新增主题切换测试
AI 生成：
feat(button): 支持主题定制，新增 primary/secondary/ghost 三种风格
用户可以通过 theme prop 切换按钮风格，CSS 变量支持全局覆盖。
包含完整的主题切换测试用例。
确认提交？[Y/n]
text
你只需要看一眼 type 对不对（feat 还是 fix）、scope 准不准（button 还是 theme），确认即可。
场景二：用 VS Code + Copilot 开发
VS Code 的 Source Control 面板有个星号图标，点击后 Copilot 自动生成 commit message：
1. 在 Source Control 面板暂存文件
2. 点击 commit 输入框旁边的 ✨ 星号图标
3. Copilot 根据暂存的 diff 生成 message
4. 审查后点击提交
text
场景三：用 Cursor 开发
# 在 Cursor 聊天框中，输入 @ → 选择 Git → 选择 Commit
@Git → @Commit 请根据这些变更生成一条 Conventional Commits 格式的提交信息
text
@Git → @Commit 引用当前未提交的变更，Cursor 理解代码上下文后生成 message。复制到 Source Control 面板提交。
场景四：终端党用 opencommit
# 安装
npm install -g opencommit
# 使用（分析 staged diff，生成 message）
oco
# 设为 Git Hook（之后 git commit 自动触发 AI 生成）
oco hook set
# 用本地模型（免费，不需要 API key）
oco --model ollama:llama3
bash
opencommit 是功能最丰富的 CLI 提交工具（GitHub 7.5k+ Star，2026-11-07 核实），支持 OpenAI/Anthropic/Ollama 等多种模型。另一个常用工具是 aicommits，用法类似，可作为备选。
顺带回应一个常见担心："哪天 AI 服务不能用了，这些命令我全忘了怎么办？"——切到本地模型即可继续获得类似服务：Ollama 或 LM Studio 都能在本机免费起一个 OpenAI 兼容端点（第2章02节讲过配置），Claude Code 与 oco 都能指向它。
选哪个
| 你的开发方式 | 用哪个 |
|---|---|
| Claude Code | 直接 /commit |
| VS Code + Copilot | 星号图标 |
| Cursor | @Git → @Commit 引用变更 |
| 终端 | oco（opencommit） |
核心逻辑都一样：AI 看 diff → 生成 message → 你审查确认。 区别只是触发方式不同。
怎么调整和定制（重点）
AI 生成的 commit message 有时候不完全符合你的要求。以下是从简单到复杂的调整方式：
调整一：当场改（最简单）
AI 生成的 message 不满意？直接告诉它哪里不对：
> scope 应该是 theme 而不是 button
> 这次应该用 fix 而不是 feat
> subject 太长了，缩短到 50 字以内
> body 里加一行说明为什么用 CSS 变量而不是 SCSS 变量
text
AI 会根据你的反馈调整后重新生成。
调整二：用 CLAUDE.md 永久生效（推荐）
把你的提交规则写在 CLAUDE.md 里，AI 每次都自动遵循：
## Git 提交规范
- 使用 Conventional Commits 格式
- commit message 使用中文 subject
- subject 不超过 50 字
- body 说明"为什么改"而非"改了什么"
- scope 使用模块名（如 button、input、theme、docs）
- 用户要求提交代码时，只提交当前会话中影响到或修改到的文件
- 不要添加 Co-Authored-By 行
markdown
倒数第二条专门防一个真实事故场景：多个窗口同时在和 AI 对话、都在改这个项目——你在一个窗口说"提交代码"，AI 可能把其他窗口还没做完的半成品一并提交进版本库，事后人工剔除非常麻烦。加上这条约束，提交范围就锁定在当前会话。
另外，不在 CLAUDE.md 里约束的话，AI 提交不一定按 Conventional Commits 格式来（比如不用中文、格式和预期不一致）——先验证一次"提交代码"的输出，再决定要不要补规则。
改一次，之后所有会话都生效。这是最推荐的定制方式。
调整三：VS Code Copilot 的定制
VS Code Copilot 通过 .github/copilot-instructions.md 文件定制：
<!-- .github/copilot-instructions.md -->
When generating commit messages:
- Use Conventional Commits format: type(scope): subject
- Write subject in Chinese, keep under 50 characters
- Always include scope based on module name
- Body should explain WHY, not WHAT
markdown
Copilot 读取这个文件后，每次生成 commit message 都遵循。跟 CLAUDE.md 的思路一样。
调整四：opencommit 的定制
opencommit 通过配置文件定制：
# 设置默认语言为中文
oco set-language zh-CN
# 自定义提示词（追加到每次生成）
oco -p "Focus on the business logic changes, not style changes"
# 自定义消息模板
oco config set OCO_MESSAGE_TEMPLATE "变更内容：$msg\n\n评审人请关注：$prompt"
bash
调整五：分拆提交
一次改了多个不相关的东西，应该拆成多个 commit：
> 当前变更涉及3个不相关的改动，请帮我拆成3个独立提交：
> 1. Button 主题功能
> 2. Input 验证修复
> 3. 文档更新
text
AI 会按文件分批暂存，生成3条独立的 commit message。
定制方式对比
| 方式 | 生效范围 | 持久性 | 适用场景 |
|---|---|---|---|
| 当场改 | 当前会话 | 一次 | 偶尔调整 |
| CLAUDE.md | Claude Code 所有会话 | 永久 | 最推荐 |
| copilot-instructions.md | VS Code Copilot | 永久 | Copilot 用户 |
| opencommit config | opencommit | 永久 | 终端党 |
提示词模板
直接复制使用的提示词：
基本提交
> 提交代码
text
带要求的提交
> 提交代码，这次是一个 bug 修复，scope 是 input
text
分拆提交
> 帮我把当前变更拆成多个提交，每个不相关的改动一个 commit
text
只提交部分文件
> 只提交 Button.vue 和 Button.test.ts，其他文件先不提交
text
修改上次提交
> 上次的 commit message 不够准确，改成：fix(input): 修复 Safari 下 placeholder 颜色不生效
text
关联 Issue
> 提交代码，commit message 里关联 Issue #42（用 Closes #42）
text
什么时候还需要 Git Hooks
Git Hooks 和 AI 平台的 Hooks 是同一个思想：在特定动作发生时自动触发检查，不依赖人的自觉。它和 AI 提交工具不冲突，而是 AI 时代的兜底安全网——AI 生成的 message 偶尔跑偏、多窗口会话里有别人未完成的改动、或者团队里有人根本不用 AI 手动提交，这些场景都需要机器在 git commit 那一刻强制把关：
- commit message 是否符合 Conventional Commits 格式（commitlint 校验）
- 暂存区代码是否通过 lint 与格式化（lint-staged）
- 提交的代码类型与内容是否匹配
按场景选择：
- 个人项目：可选。AI 生成的 message 天然规范，但想强制自己（和 AI）守住格式底线，配一套也只要一分钟，很有意义
- 团队项目：必配。只要有人手动提交，hooks 就是唯一防线
配置交给 AI，一条提示词搞定（第4节有完整演示，AI 会装好 lint-staged、commitlint 与 conventional 预设，全程不到两分钟）：
请为当前 Vue3 项目配置 Git Hooks：
1. 安装 husky + lint-staged + commitlint（用 conventional 预设）
2. pre-commit：跑格式化 + lint
3. commit-msg：校验 Conventional Commits 格式
4. lint-staged 配置用 Biome（新项目）或 ESLint + Prettier（老项目）
text
本节要点
- 规范知道就行，具体交给 AI：Conventional Commits 格式（feat/fix/docs/refactor/test/build/chore/perf/style），与分支命名同一套词汇
- 提交前先配用户信息：没配置会留下"默认用户名+主机名"的脏记录，一句自然语言配好并修正历史提交
- 怎么用：Claude Code 说"提交代码"或官方插件市场的
/commit、VS Code 点星号、Cursor 用 @Git → @Commit、终端用 oco - 怎么调：当场改最简单、CLAUDE.md 永久生效最推荐（含"只提交当前会话文件"防多窗口误提交）、copilot-instructions.md 给 Copilot 用
- 提示词模板直接复制：基本提交、分拆、只提交部分文件、关联 Issue（关联 Issue 需要远端平台 API Key，第5节 CI/CD 会用到）
- Git Hooks 是兜底安全网：个人项目可选（一分钟配好），团队项目必配——commitlint 守格式，lint-staged 守代码
下一节讲缺陷管理与 AI 调试——提交之后，如何在项目级别把质量问题拦在发生之前。
↑